home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 4368 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.3 KB  |  81 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: newsfeed.pitt.edu!dsinc!scala!darren
  3. From: darren@scala.scala.com ("Darren M. Greenwald")
  4. Subject: Re: doubling pixels horizontally
  5. Message-ID: <1996Feb28.090905.19028@scala.scala.com>
  6. Date: Wed, 28 Feb 1996 09:09:05 GMT
  7. References: <2824.6626T859T1819@ifi.uio.no> <2637.6627T383T87@login.eunet.no> <719.6629T1277T1909@ifi.uio.no>
  8. Organization: US Research and Development - Scala Inc.
  9.  
  10. In article <719.6629T1277T1909@ifi.uio.no> ludvigp@ifi.uio.no (Ludvig Pedersen) writes:
  11. >>Well, why do that peace of code get executed then, and not the other one?
  12. >>Ahh... now i know. Its the damn wait loop that locks the task, so the task
  13. >>gets bussy in the wait loop, and never gets to the cleanup routine.
  14. >>I stil think its a bug in QBlit. It should be called from from the blit
  15. >>interrupt. Waiting with a test loop insnt that OS friendly though.
  16. >>There is a solution though, with out signaling the task, but who wants to
  17. >>do that anyway.
  18. >
  19. >Yes, instead of using Signal()/Wait() one can also have an extra dummy
  20. >blitterpass which sets the flag instead of the CleanUp routine.
  21. >
  22. >But I agree it is a small bug.
  23. >
  24.  
  25. You have to be really careful with busy loops.  There is a very
  26. real possibility that at the time you QBlit, the blitter is being
  27. held by some other lower priority task (for blits started with
  28. Own/DisBlitter).  If that happens, and you lock out the other
  29. task, and the other task does not ever get around to releasing
  30. the blitter, the queued blit won't be started, and you will sit
  31. there waiting forever.
  32.  
  33. It is unlikely he is being affected by this, but the info may help.
  34. There is a hardwware bug that can cause the blitter to lock up, but
  35. it was only ever seen in some of the programmable video modes.
  36. It is possible that it exists in other video modes, but again,
  37. it was never seen.  There is a fine song and dance played
  38. between blitter interrupt servicing, and vertical blank servicing
  39. to avoid this bug, but I could well imagine the bug being made
  40. to surface by long disables, or by adding a vertical blank server
  41. ahead of graphics.  My recollection is that vertical blank handling
  42. was not rewritten in all of the ways it would need to be to entirely
  43. avoid this bug (this would have required a significant rewrite, and
  44. the bug was not found until near the very end of the AA software
  45. project).  The bug has to do with when some of the programmable
  46. registers are written to, and there are a few timing slots during
  47. which writing some of these registers can cause the DMA slot
  48. allocation to slip it's normal priority scheme.  The result being
  49. that chip register addresses inside the chip collide, and a common
  50. collision case results in the blitter state machine to lock up.  The
  51. other reason that this was not entirely fixed for KS 3 is that
  52. when this was found, there where a few common cases that could
  53. be produced regularly, and observed with dualing analyzers (one
  54. for the CPU, one for the RGA bus).  It would have required much
  55. more time for the hardware engineers to determine absolutely that
  56. all possible cases where understood.  Delaying the product for
  57. that much longer was unrealistic, so instead, a reasonable work
  58. around was introduced in to software (with the caveats above), and
  59. stress tests where run for a couple of weeks running combinations
  60. of queued blits, own/disown blits, sprites, in various video modes
  61. that where known to show the problem.
  62.  
  63. Still, I could not tell you with absolute 100% certainty that every
  64. possible case was found, or worked around.  I can tell you that using
  65. the system in the perscribed ways was stress tested thoroughly, but
  66. it is definitely possible to abuse the system in ways that would
  67. exhasberate the bug.  Really the a full solution would require
  68. the hardware engineers to prove that all possible cases are understood,
  69. and further to rewrite various portions of the vertical blanking routines,
  70. and likely some pieces in graphics to utterly and entirely check for
  71. and avoid writing to dangerous registers at the wrong time.  That, or
  72. fix it in hardware (a software fix is probably sufficient though).
  73.  
  74.  
  75.  
  76. -- 
  77. -----------------------------------------------------------
  78. Darren M. Greenwald         | Scala Inc. R&D            /
  79. Senior Systems Engineer     | darren@scala.com         o
  80. -----------------------------------------------------------
  81.